Portions of this patent application contain materials that are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document, or the patent disclosure, as it appears in the Patent and Trademark Office. All other rights are expressly reserved.
This invention relates generally to improvements in computer systems and, more particularly, to operating system software for managing user interface objects in a windows-oriented graphical user interface.
One of the most important aspects of a modern computing system is the interface between the human user and the machine. The earliest and most popular type of interface was text based; a user communicated with the machine by typing text characters on a keyboard and the machine communicated with the user by displaying text characters on a display screen. More recently, graphic user interfaces have become popular in which the machine communicates with the user by displaying graphics, including text and pictures, on a display screen and the user communicates with the machine both by typing in text-based commands and by manipulating the displayed pictures with the pointing device, such as a mouse.
Many modern computer systems operate with a graphic user interface called a xe2x80x9cwindow environmentxe2x80x9d in which the main user interface object is the xe2x80x9cwindowxe2x80x9d. In a typical window environment, the graphical display portrayed by the display screen is arranged to resemble the surface of an electronic xe2x80x9cdesktopxe2x80x9d and each application program running on the computer is represented as one or more electronic xe2x80x9cpaper sheetsxe2x80x9d displayed in rectangular regions of the screen called xe2x80x9cwindowsxe2x80x9d.
Each rectangular region generally displays information which is generated by the associated application program and there may be several window regions simultaneously present on the desktop with each window region representing information generated by different application programs. An application program presents information to the user through each window by drawing or xe2x80x9cpaintingxe2x80x9d images, graphics or text within the window region. The user, in turn, communicates with the application both by xe2x80x9cpointingxe2x80x9d at objects in the window region with a cursor which is controlled by a pointing device and manipulating or moving the objects and also by typing information into the keyboard. The window regions may also be moved around on the display screen and changed in size and appearance so that the user can arrange the desktop in a convenient manner.
There may be several types of windows associated with each application programxe2x80x94these windows include the main window, which is always present, and other windows such as xe2x80x9cpop-upxe2x80x9d windows which appear in response to a specific user or program action. Pop-up windows include a type of window called a xe2x80x9cdialogxe2x80x9d box which is a type of pop-up window that appears on the screen for a short duration of time and accomplishes a specific task, such as obtaining a file name or performing a selection. Simple applications may include only the main window, while complicated applications may use tens and ever hundreds of pop-up windows and dialog boxes. There are also windows, called palettes and panels that are always on the screen and utilized in conjunction with the main window. They typically float above the main window facilitating easy access to commands, colors or direct manipulation elements.
The windows, in turn, include other user interface objects such as, scroll bars which can be used to move or change the portion of the window which is displayed and menu systems that allow a user to select various commands and actions. In addition, window environments also typically provide xe2x80x9cstandardxe2x80x9d user interface objects called xe2x80x9ccontrolsxe2x80x9d which can be displayed in the windows and manipulated by the user. The standard objects allow all of the application programs which run with a given GUI to have the same xe2x80x9clook and feelxe2x80x9d and, thus, user learning time is generally reduced.
The standard objects can include push buttons which are generally rectangular areas of the window which are rendered to appear as a xe2x80x9cthree-dimensionalxe2x80x9d button. The push-button has built-in behavior which is controlled by the window system to change the screen appearance of the button so that the button appears to be xe2x80x9cpushed inxe2x80x9d when the button display area is selected. Other selection displays include xe2x80x9ccheckboxesxe2x80x9d which can display a check mark or other indicia to indicate a selection and xe2x80x9cradio buttonsxe2x80x9d which are a set of check boxes in which selection of one box deselects the other boxes in the set.
Other standard user interface objects include objects which display items. These displays include text display areas and graphics display areas. The text display areas may include a simple line of text which displays text but cannot be edited. More complicated displays include list boxes which display a scrollable list of either graphical or text items and drop-down list boxes which appear as a single line but expand to a list when a predefined area is selected. With list boxes and drop-down lists the user may be able to select items as well as manipulate the displays. Still more complicated display areas include edit areas which are rectangular areas that allow the user to edit text using predefined commands. Some window environments allow the users to design their own controls which may be combinations of existing controls or entirely new controls with custom behaviors.
The graphic display areas can include user-designed bit map graphics, icons and customer user graphics.
In most windows systems, the overall behavior and appearance of the aforementioned windows and controls are determined by the portion of the operating system known as a xe2x80x9cgraphical user interfacexe2x80x9d (GUI) or the xe2x80x9cgraphical device interfacexe2x80x9d (GDI). Instead of an application program drawing and controlling the user interface, object, the GUI system actually renders the interface object on the display screen and controls appearance changes due to user selection movement and manipulation. User manipulations of the object are communicated to the application program by messages that are sent from the GUI to the application program and the application program controls the interface objects by sending messages to the GUI.
Even though an application program does not actually control drawing of the interface objects, the application program must initially specify parameters such as the size, position and appearance attributes (such as colors) for each user interface object to the GUI so that the object can be initially rendered in the desired position with the proper appearance. In many windows environments, the user interface object parameters are stored in a xe2x80x9cresourcexe2x80x9d file in which each user interface object is assigned an identifier and associated with a list of parameters for that object. During the normal application program development cycle, after the application program is written and compiled, the resource file is also compiled and the resource object file is xe2x80x9cboundxe2x80x9d to the object file of the application program. Thereafter, during the operation of the application program, a user interface object is drawn on the screen by making a function call to the GUI and including the resource file identifier as a parameter in the function call. The GUI then reads the resource file and extracts the necessary parameters to render the interface object.
The structure and format of the resource file are fixed by the GUI and it is possible for an application program developer to directly compose and edit the resource file. However, direct composition and editing of the file is extremely tedious since each interface object generally has many separate parameters, all of which must be included to properly render the object. In addition it is often very difficult to position the objects with respect to each other and compose and entire screen display simply by looking at the parameter lists for each object.
Accordingly, user interface objects are generally designed by means of a xe2x80x9cresource editorxe2x80x9d program. This latter program uses the contents of a resource file to generate displays of the user interface objects contained therein which displays appear on the display screen in the same manner as they would appear when drawn by the GUI as the application program is actually being run. The application program developer can manipulate the object displays and, in response, the resource editor program edits the resource file parameters to insure that the user interface objects will appear properly when drawn by the GUI.
While the resource editor approach works well with small to medium size projects, for large projects it becomes a bottleneck. A large development project may have hundreds, or even thousands, of user interface objects. In addition, many programmers may simultaneously be working on parts of a project or several different projects which, although separate, share user interface objects. If a single resource file is used for the entire project, then the normal development cycle of compile, link, test and debug results in the resource file being compiled over and over or worse, results in developers having to wait for the file to be free. If several smaller resource files are used, then some method must be used to insure that duplicated interface objects are kept up to date and that everyone is using the latest versions.
Further, the resource file/editor approach is not flexible. In particular, the resource editor is designed to work with a predefined set of user interface objects. If a new user interface object is designed, then the resource editor must be rewritten to accommodate this new object. Consequently, the conventional resource editor approach is a poor choice in flexible development environments such as object-oriented development environments which are designed to be easily extensible.
In addition, the traditional resource file/editor approach is not easily adaptable to multi-lingual environments where the text appearing in the user interface must be translated into a local language to allow the program to work in foreign countries. The normal manner of handling this problem is to consolidate all text strings in a separate xe2x80x9cstring tablexe2x80x9d. Rather than coding a text string directly into program code, the corresponding text is inserted as an entry in the string table along with an identifier. The application program code uses the identifier to retrieve the appropriate string at run-time from the string table and the string is then displayed. Since most of the text is located in a single table, the task of translating the text into a local language is greatly simplified.
The string table approach suffers from the same problems as the resource file. First, a single string table becomes a bottleneck during the normal development cycles. Second, multiple string tables must be coordinated to avoid different text strings from being associated with the same interface object. In addition, although conventional string tables contain most of the text information for a development project, a significant amount of text still becomes embedded directly into the program. This latter text includes menu headings and menu option lines, text found on button faces, and miscellaneous text displays. Accordingly, the job of translating an application program into a new language still remains a tedious and time-consuming job. This remains true even if the text portions of some of the user interface objects have already been translated, since the remainder of the text must still be found and translated.
Accordingly, it is an object of the present invention to provide a user interface object archiving system which can manage user objects to insure consistency between various sections of a project or various projects which utilize common objects.
It is another object of the present invention to provide a user interface object archiving system which can easily accommodate newly-designed user interface objects without requiring a rewrite of the object editor.
It is still a further object of the present invention to provide a user interface archiving system which facilitates the translation of the text in an application to an alternative language.
The foregoing problems are overcome and the foregoing objects are achieved in one illustrative embodiment of the invention in which user interface objects are stored in a user interface object archive which is a database physically located in the shared library of an associated application program. In order to facilitate xe2x80x9clocalizationxe2x80x9d, or preparation of an application developed in one language for use in an xe2x80x9careaxe2x80x9d or a locale which uses another language, the user interface objects are stored in a hierarchical locale tree within the archive. As the tree proceeds away from the root locale the locales become more-and-more specific as to language. All objects are stored in the base or root of the hierarchy, but only those objects which require a translation are stored in an area associated with a more specific locale. At runtime, a complete collection of objects is assembled by starting at the desired locale and proceeding up the hierarchy level-by-level. Translated objects at lower levels of the hierarchy xe2x80x9coverridexe2x80x9d those at higher levels so that the most complete translations of each object are obtained during this search.
The user interface objects which are stored in an archive are actually created via a separate xe2x80x9cconstructorxe2x80x9d program which is used by application developers to edit standard user interface objects and to create new user interface object. In order to allow newly-created user interface objects to use the predesigned constructor program, each user interface object is contained in a special xe2x80x9cescortxe2x80x9d object that actually interfaces with the constructor program. The user interface object is stored at the appropriate locale in the archive, while the escort object is not saved. However, when an archived object is requested, the related escort object is queried and streams out the attributes of the enclosed UI object. The escort object itself remains in the archive. Therefore, functions and variable instances which are necessarily included in the escort object which allow it to interact with the constructor program do not end up in the application program.